In an application server or run-time environment which includes a virtual machine, for example the Java Virtual Machine from Sun Microsystems or the JRockit Virtual Machine from Bea Systems, Inc., resources are constantly being created and used to service client and server requests. The typical virtual machine (VM) environment exists on a server that includes an operating system and memory space. As the VM executes, servicing client requests and running applications, it creates object instances in the memory of the VM or server. As the system operates this memory space is continuously used up with new objects and other resources. The typical VM environment includes a garbage collection mechanism that is used to clean up the memory space and to remove those resources that are no longer needed. Most common garbage collection methods operate on the basis of automatically freeing up resources that are no longer used, i.e., that include objects which are no longer referred to by other objects. However, a common problem with all existing garbage collection mechanisms is that of memory leakage. During the development of a typical software application, objects may be specified by the developer that may unknowingly point to other objects. During run-time, this object may then point to another object which is no longer needed. If an object that is no longer needed and yet still exists in memory space because of such invalid requests or pointers, this is considered a memory leak and is undesirable. Because the object is never freed up, the memory space it occupies cannot be used by other resources. This is a particular problem when objects are continuously created during run-time but are never freed up, so that eventually the entire memory space of the virtual machine fills up and the machine or computer typically needs to be restarted.
The traditional approach to detecting and analyzing potential memory leaks during the software development process is to create an object display object map for the developer that illustrates all of the preferred objects in the memory space, and then highlights or otherwise displays to the developer those objects that may represent potential memory leaks. The problem with this method is that it only gives a high level view of the object map, and provides very little useful information to the developer to accurately determine large scale memory leaks and find the responsible object or objects. Since the vast number of objects represented on the display tend to overwhelm the important information, i.e., which objects are prone to creating memory leaks, it is doubtful that this large scale object display is of much use to the developer.
Besides this traditional method of creating object maps, little else has been done in the software development field for creating tools that allow a virtual machine application developer to accurately access their application for potential memory leaks. Any new technique that would assist the developer in detecting such memory leaks would provide a significant advantage to the software developer, and would result in cleaner applications that minimize the need to restart the virtual machine on such a regular basis.